6. 클라우드 컨테이너 서비스 (AWS)

6.1. 클라우드의 컨테이너 지원 현황: 주요 클라우드의 다양한 컨테이너 서비스

6.1.1. AWS 의 컨테이너 서비스

• AWS(Amazon Web Services): IaaS 및 PaaS 시장에서 압도적인 점유율을 가진 아마존의 클라우드 서비스
• 컨테이너 실행 환경을 제공하는 서비스
  • 아마존 ECS (Elastic Container Service)
  • 아마존 EKS (Elastic Kubernetes Service)
  • AWS Fargate
• 컨테이너 레지스트리
  • 아마존 ECR (Elastic Container Registry): 클라우드에서 컨테이너 이미지를 관리

6.1.4. 각 클라우드에서 제공하는 컨테이너 서비스 (AWS)

AWS 컨테이너 서비스 지도:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  [Amazon ECR]  ← 컨테이너 이미지 저장소
       │ 이미지를 가져옴(pull)
       ▼
  ┌─ 오케스트레이션 (무엇을, 몇 개, 어떻게 운영할지) ─
  │   ├─ Amazon ECS : AWS 독자 방식
  │   └─ Amazon EKS : 쿠버네티스 방식
  │
  └─ 실행 위치 (컨테이너가 실제로 도는 곳) ─
      ├─ EC2        : 내가 고른 가상 서버 (클러스터 관리 필요)
      └─ Fargate    : 서버리스 (클러스터 관리 불필요)

6.1.5. 어떤 클라우드 서비스를 사용해야 할까?

• 주요 클라우드는 모두 컨테이너 서비스를 제공함
  • 세부 사항에는 차이가 있지만 서비스 내용에는 공통점이 많음
• 선택 기준은 종합적 판단
  • 컨테이너 서비스의 내용·가격
  • 컨테이너 이외의 점: 정보 보안 관리 시스템 인증(ISMS 등) 같은 요건
• 컨테이너는 서로 다른 플랫폼 간 마이그레이션이 쉽도록 이식성을 지향하는 기술
  • 어느 하나가 아닌 여러 클라우드를 병용하는 멀티 클라우드도 선택지가 됨

6.2. 아마존 ECS: AWS 의 컨테이너 오케스트레이션 서비스

6.2.1. 아마존 ECS 란

• 아마존 ECS: 컨테이너를 오케스트레이션하는 AWS 의 서비스
  • 쿠버네티스와는 다른 독창적인 컨테이너 오케스트레이션 서비스
  • 컨테이너 관리 및 운영을 자동화할 수 있음
• AWS 가 서버, OS 등의 인프라를 관리·운영하는 서비스 → 직접 관리하는 것보다 부하가 줄어듦
• 컨테이너 이미지 관리 기능은 없음 → AWS 의 다른 서비스인 아마존 ECR 로 이미지를 등록·배포

시작 유형: Fargate vs EC2

ECS 를 사용할 때는 시작 유형(Launch Type) 중 하나를 선택해야 함.

시작 유형별 책임 범위:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  [EC2 시작 유형]                    [Fargate 시작 유형]
  ┌ 사용자 ────────────┐            ┌ 사용자 ────────────┐
  │ 컨테이너 정의       │            │ 컨테이너 정의       │
  │ EC2 인스턴스 선택    │            │ CPU · 메모리 지정   │
  │ 클러스터 확장·패치   │            └────────────────────┘
  └────────────────────┘            ┌ AWS ───────────────┐
  ┌ AWS ───────────────┐            │ 서버 · OS · 클러스터 │
  │ 오케스트레이션 제어  │            │ 오케스트레이션 제어  │
  └────────────────────┘            └────────────────────┘

6.2.2. 아마존 ECS 의 작동 방식

• 쿠버네티스: 4계층 구조
  • 디플로이먼트 > 레플리카셋 > 파드 > 컨테이너
• 아마존 ECS: 3계층 구조
  • 서비스 > 태스크 > 컨테이너 (태스크당 컨테이너 최대 10개)

쿠버네티스 vs 아마존 ECS 계층 비교:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  쿠버네티스 (4계층)                 아마존 ECS (3계층)
  ─────────────────                  ─────────────────
  디플로이먼트  ─┐
                ├─ 같은 역할 ──→    서비스
  레플리카셋    ─┘                    │
     │                               │
  파드          ── 같은 역할 ──→    태스크 (컨테이너 최대 10개)
     │                               │
  컨테이너      ── 같은 역할 ──→    컨테이너

• 각 태스크에 AWS 네트워크 인터페이스인 ENI(Elastic Network Interface) 를 할당하는 등, 쿠버네티스(파드마다 IP)와 공통점이 많음

6.2.3. 아마존 ECS 의 장단점

6.2.4. 쿠버네티스가 있다면 아마존 ECS 는 불필요할까?

• 쿠버네티스와 ECS 는 둘 다 컨테이너 오케스트레이션 도구 → 할 수 있는 것에 공통점이 많음
• 아마존 EKS 로도 인프라 관리를 AWS 에 맡기면서 쿠버네티스를 쓸 수 있음
• 그래도 ECS 가 필요 없는 것은 아님
  • 자동 빌드 서비스 AWS CodePipeline, 자동 배포 서비스 AWS CodeDeploy 와의 연계 기능을 표준으로 갖춤
  • 경우에 따라 ECS 가 더 쉽고, 애플리케이션 개발·운영을 단순화할 수 있음

6.3. 아마존 EKS: AWS 의 쿠버네티스 서비스

6.3.1. 아마존 EKS 란

• 아마존 EKS: 쿠버네티스 컨테이너 오케스트레이션을 수행하는 AWS 의 서비스
  • 쿠버네티스 클러스터의 관리·운영을 자동화
  • 관리형 서비스 → 직접 인프라를 관리하는 것보다 부하가 줄어듦
• ECS 와 비슷한 서비스지만 플랫폼이 쿠버네티스라는 점이 다름
• 워커를 만들지 않고 파드를 실행할 수 있는 Fargate 같은, 쿠버네티스 자체에는 없는 고유 기능도 제공

6.3.2. 아마존 EKS 의 작동 방식

• 쿠버네티스 클러스터가 마스터 + 워커로 구성되듯, EKS 클러스터는 EKS 컨트롤 플레인 + EKS 워커 노드로 구성됨

• EKS 는 고가용성을 보장하는 메커니즘을 제공함 → 이해하려면 리전과 가용 영역을 알아야 함

6.3.3. 리전과 가용 영역

• 리전(Region): AWS 가 데이터 센터를 지리적 단위로 나눈 것 (예: 서울 리전)
• 가용 영역(AZ, Availability Zone): 리전을 구성하는 서로 독립된 데이터 센터 묶음
  • 한 가용 영역에 장애가 나도 같은 리전의 다른 가용 영역에는 영향이 없도록 설계됨
• EKS 컨트롤 플레인과 워커 노드를 여러 가용 영역에 배치하면, 한 가용 영역에 장애가 나도 클러스터가 멈추지 않고 계속 실행됨

리전 · 가용 영역과 EKS 배치:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  [리전: 서울 ap-northeast-2]
   │
   ├─ 가용 영역 A ── 컨트롤 플레인 일부 ── 워커 노드 (EC2)
   ├─ 가용 영역 B ── 컨트롤 플레인 일부 ── 워커 노드 (EC2)
   └─ 가용 영역 C ── 컨트롤 플레인 일부 ── 워커 노드 (EC2)

  가용 영역 A 장애 발생
   → B · C 의 컨트롤 플레인과 워커 노드가 계속 동작
   → 클러스터 중지 없음

6.3.4. 아마존 EKS 의 장단점

• 장단점은 ECS 와 비슷함
  • 인프라를 관리할 필요가 없다는 점, AWS 의 다른 서비스와 통합되어 있다는 점은 상황에 따라 장점도 단점도 됨
• ECS 와 달리 EKS 는 쿠버네티스라는 다른 클라우드와 공통된 플랫폼 위에 구축됨
  • AWS 에서 AWS 가 아닌 곳의 쿠버네티스 클러스터로 마이그레이션할 때 ECS 보다 유리
• 다만 쿠버네티스를 공유하더라도 쉽게 옮길 수 있는지는 컨테이너 설계에 달려 있음 → 반드시 장점이라고는 할 수 없음
• EKS 와 ECS 중 어느 것이 낫다고 간단히 비교할 수 없음 → 둘 다 알고 상황에 맞게 쓰는 것이 이상적

6.4. AWS Fargate: AWS 의 서버리스 컨테이너 실행 환경

6.4.1. AWS Fargate 란

• AWS Fargate: 서버리스 컨테이너 실행 환경을 제공하는 AWS 서비스
  • 컨테이너 이미지를 지정하는 것만으로 컨테이너를 실행
  • 컨테이너를 시작하면 도커 허브나 아마존 ECR 같은 레지스트리에서 이미지를 가져옴
• ECS·EKS 의 EC2 방식과 달리 클러스터를 관리할 필요가 없음 → 운영 부하 감소
• 원서 설명: Fargate 는 독립 서비스가 아니라 ECS 의 선택 기능 중 하나
• 사용하려면 컨테이너가 쓸 리소스(CPU·메모리)를 지정해야 함
• 요금: 리소스 사용량 × 사용 시간 기준. 컨테이너를 실행하지 않으면 요금 없음

6.4.2. AWS Lambda 와 차이점

• AWS Lambda: AWS 의 서버리스 프로그램 실행 환경
  • 소스 코드를 업로드하는 것만으로 프로그램 실행
• 시작할 때 지정하는 것이 소스 코드인지, 컨테이너 이미지인지에 따라 Fargate 와 구분되지만, 실행 환경을 제공한다는 점에서는 같은 역할

6.9. 도커 엔터프라이즈: 중앙 집중식 관리를 통해 멀티 클라우드 실현

6.9.1. 도커 엔터프라이즈란

• 도커 엔터프라이즈: 컨테이너를 활용한 애플리케이션을 개발·운영하기 위한 유료 플랫폼
  • 테스트·인증된 버전의 도커에서 애플리케이션을 개발·운영할 수 있음
  • 서브스크립션을 구입하면 우선 지원을 받을 수 있음
• 제품 구성은 두 가지

• 지원 기간 비교 (원서 기준)
  • 오픈 소스 버전 도커: 릴리스부터 7개월
  • 도커 엔진 - Enterprise: 릴리스부터 24개월 → 보안 업데이트·버그 수정을 장기간 지원

6.9.2. 도커 엔터프라이즈에서 사용 가능한 도구

도커 엔터프라이즈의 멀티 클라우드 관리 (원서 기준):
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

          [Federated Application Management]
                     (중앙 관리)
                         │
       ┌─────────────────┼─────────────────┐
       ▼                 ▼                 ▼
  온프레미스          클라우드          주요 클라우드의
  도커 엔터프라이즈    도커 엔터프라이즈   관리형 쿠버네티스
  (UCP + DTR)        (UCP + DTR)       (예: Amazon EKS)

핵심 요약

6장. 클라우드 컨테이너 서비스 (AWS) 요약:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[AWS 컨테이너 서비스 4종]
├─ ECS     : AWS 독자 오케스트레이션
├─ EKS     : 관리형 쿠버네티스
├─ Fargate : 서버리스 컨테이너 실행 환경 (ECS · EKS 모두 사용)
├─ ECR     : 컨테이너 이미지 레지스트리
└─ 선택 기준: 서비스 내용·가격 + 보안 인증 등 종합 판단, 멀티 클라우드도 검토

[Amazon ECS]
├─ 3계층: 서비스 > 태스크(컨테이너 최대 10개) > 컨테이너
├─ 서비스 = 디플로이먼트 + 레플리카셋 역할, 태스크 = 파드 역할
├─ 서비스·태스크 정의 = JSON 으로 선언 (매니페스트 역할)
├─ 실행 위치: Fargate(관리 불필요, 안 돌면 무료) / EC2(세밀한 설정, 켜져 있으면 과금)
├─ 장점: 인프라를 AWS 에 맡김, AWS 서비스 연동이 쉬움
└─ 단점: 보안 요건에 따라 부담, AWS 의존으로 멀티 클라우드 어려움

[Amazon EKS]
├─ 관리형 쿠버네티스: EKS 컨트롤 플레인(AWS 관리) + 워커 노드(EC2)
├─ 리전 > 가용 영역(독립) → 여러 AZ 에 두면 한 AZ 장애에도 계속 동작
├─ 컨트롤 플레인 다중 AZ 는 AWS 가 자동, 사용자는 워커 노드를 AZ 에 분산
├─ ECS 대비: 쿠버네티스 표준이라 이식성 높음 (단, 설계에 달림)
└─ 둘 다 알고 상황에 맞게 선택하는 것이 이상적

[AWS Fargate vs Lambda]
├─ Fargate: 컨테이너가 계속 떠서 서비스, 제약이 적음 (장시간·대용량)
└─ Lambda : 이벤트가 올 때만 실행, 최대 15분, 이벤트 중심 동작에 강점

[도커 엔터프라이즈 (원서 기준)]
├─ 유료 플랫폼: 인증된 도커 + 우선 지원 + 장기 지원(24개월)
├─ UCP: 스웜 + 쿠버네티스 공존 / DTR: 온프레미스 프라이빗 레지스트리
├─ Federated Application Management: 멀티 클라우드 중앙 관리
└─ 현재: 2019년 Mirantis 매각 → MCR · MKE · MSR 로 이름 변경

참고 자료

관련 자료:

• Amazon ECS: https://aws.amazon.com/ecs/
• Amazon EKS: https://aws.amazon.com/eks/
• Amazon EKS 아키텍처 (컨트롤 플레인 다중 AZ): https://docs.aws.amazon.com/eks/latest/userguide/eks-architecture.html
• Amazon EKS 요금: https://aws.amazon.com/eks/pricing/
• AWS Fargate: https://aws.amazon.com/fargate/
• Amazon ECR: https://aws.amazon.com/ecr/
• ECS 블루/그린 배포 내장 (2025-07): https://aws.amazon.com/about-aws/whats-new/2025/07/amazon-ecs-built-in-blue-green-deployments/
• ECS Managed Instances (2025-09): https://aws.amazon.com/about-aws/whats-new/2025/09/amazon-ecs-managed-instances
• AWS Lambda 할당량: https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html
• Mirantis 의 도커 엔터프라이즈 인수 (2019-11): https://www.mirantis.com/company/press-center/company-news/mirantis-acquires-docker-enterprise/

함께 보면 좋은 노트:

• 10주차: 관리형 Kubernetes(PaaS): 관리형 K8s 에서 클라우드가 맡는 것과 SA 설계 체크리스트

네비게이션